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Foreword 



rd , 



This Technical Specification has been produced by the 3"^ Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the interfaces and Terminal Adaptation Functions (TAF) integral to a Mobile 
Termination (MT) which enable the use of asynchronous bearer services in the PLMN and the attachment of 
asynchronous terminals to a MT (see 3GPP TS 04.02 [3] and 3GPP TS 23.101 [6]). 

The general aspects of Terminal Adaptation Functions are contained in 3GPP TS 27.001 [10]. 

The present document covers support of these services for the following interfaces and procedures: 

(i) ITU-T V.14 [16] procedures. 

(ii) ITU-T V.21 [17] DTE/DCE interface. 

(iii) ITU-T V.22bis [18] DTE/DCE interface. 

(iv) ITU-T V.32 [24] DTE/DCE procedures. 

(v) ITU-T 1.420 [14] S interface, 

(vi) ITU-T V.250 [22] signalling procedures. 

The asynchronous data rates between the MT and the IWF are defined in 3GPP TS 22.002 [5]. 

NOTE: From GSM R99 onwards the following services are no longer required a GSM PLMN: 

the dual Bearer Services "alternate speech/data" and "speech followed by data"; 

the dedicated services for PAD and Packet access; 

- the BS 21 ...26 and BS 31 ...34. 

The support of these services is still optional. The specification of these services is not within the scope of the present 
document. For that, the reader is referred to GSM Release 98. 

Descriptions related to facsimile are not applied to UMTS but to GSM. 



1.1 References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[1] 3GPP TS 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and 

acronyms". 

[2] 3GPP TS 03. 10: "Digital cellular telecommunication system (Phase 2+); GSM Public Land Mobile 

Network (PLMN) connection types". 

[3] 3GPP TS 04.02: "Digital cellular telecommunication system (Phase 2+); GSM Public Land Mobile 

Network (PLMN) access reference configuration". 

[4] 3GPP TS 04.21: "Digital cellular telecommunication system (Phase 2+); Rate adaption on the 

Mobile Station - Base Station System (MS - BSS) interface". 

[5] 3GPP TS 22.002: "Circuit Bearer Services (BS) supported by a PubUc Land Mobile Network 

(PLMN)". 

[6] 3GPP TS 23.101: "General UMTS Architecture". 

[7] 3GPP TR 23.910: "Circuit Switched Data Bearer Services". 
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[8] 3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols-Stage 

3". 

[9] 3GPP TS 24.022: "Radio Link Protocol (RLP) for Circuit Switched Bearer and Teleservices". 

[10] 3GPP TS 27.001: "General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)". 

[11] 3GPP TS 27.007: "AT command set for 3G User Equipment (UE)" . 

[12] 3GPP TR 21.905: "3G Vocabulary". 

[13] 3GPP TS 29.007: "General requirements on Interworking between the PLMN and the ISDN or 

PSTN". 

[14] ITU-T Recommendation 1.420 (1998):"Basic user-network interface". 

[15] ITU-T Recommendation V.4 (1988): "General structure of signals of international alphabet No. 5 

code for character oriented data transmission over public telephone networks". 

[16] ITU-T Recommendation V.14 (1993): "Transmission of start-stop characters over synchronous 

bearer channels". 

[17] ITU-T Recommendation V.21 (1988): "300 bits per second duplex modem standardized for use in 

the general switched telephone network" . 

[18] ITU-T Recommendation V.22bis (1988): "2400 bits per second duplex modem using the 

frequency division technique standardized for use on the general switched telephone network and 
on point-to-point 2-wire leased telephone-type circuits". 

[19] ITU-T Recommendation V.24 (1996): "List of definitions for interchange circuits between data 

terminal equipment (DTE) and data circuit- terminating equipment (DCE)". 

[20] ITU-T Recommendation V.25 (1996): "Automatic answering equipment and general procedures 

for automatic calling equipment on the general switched telephone network including procedures 
for disabling of echo control devices for both manually and automatically established calls". 

[21] Void. 

[22] ITU-T Recommendation V.250: "Serial asynchronous automatic dialling and control". 

[23] ITU-T Recommendation V.28 (1993): "Electrical characteristics for unbalanced double-current 

interchange circuits". 

[24] ITU-T Recommendation V.32 (1993): "A family of 2-wire, duplex modems operating at data 

signalling rates of up to 9600 bit/s for use in the general switched telephone network and on leased 
telephone-type circuits". 

[25] ITU-T Recommendation V.42 (1996): "Error-correcting procedures for DCEs using 

asynchronous-to-synchronous conversion" . 

[26] ITU-T Recommendation V.42 bis (1990): "Data compression procedures for data circuit- 

terminating equipment (DCE) using error correction procedures". 

[27] ITU-T Recommendation V.llO (1996): "Support of data terminal equipments with V-Series 

interfaces by an integrated services digital network". 

[28] ITU-T Recommendation X.28 (1997): "DTE/DCE interface for a start-stop mode Data Terminal 

Equipment accessing the Packet Assembly/Disassembly facility (PAD) in a public data network 
situated in the same country" . 

[29] Personal Computer Memory Card Association: "PCMCIA 2.1 or PC-Card 3.0 electrical 

specification or later revisions". 
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[30] Infrared Data Association IrDA "IrPHY Physical layer signalling standard". 

[31] ISO 2110: "Data communication - 25-pole DTE/DCE interface connector and contact number 

assignments". 

[32] ITU-T Recommendation Q.93 1 : "ISDN user-network interface layer 3 specification for basic call 

control". 

1 .2 Abbreviations 

In addition to the abbreviations used in the present document that are listed in either 3GPP TS 01.04 [1] or TR 21.905 
[12] the following internal abbreviations are used: 



ITU 


International Telecommunications Union 


CFI 


Call Failure Indication 


CRN 


Call Request with Number 


Die 


Disregard Incoming Call 


IA5 


International Alphabet no. 5 


INC 


INcoming Call 


INV 


INValid 


ITU-T 


ITU-Telecommunication Standardization Sector 


VAL 


VALid 


XID 


Exchange IDentification (frame) 


3 


Definitions 



The term 'mobile station' (MS) in the present document is synonymous with the term 'user equipment' (UE ) in 3G 
terminology as defined in 3GPP TR 21.905. 

The term 'TE2' in the present document is synonymous with the term 'TE' in 3G terminology as defined in 3GPP 
TR 21.905. 

The term 'MT2' in the present document is synonymous with the term 'MT' in 3G terminology as defined in 3GPP 
TR 21.905. 



2 Reference Configuration 

3GPP TS 27.001 [10], 3GPP TS 23.101 [6] and 3GPP TS 04.02 [3] describe the basic reference configurations. 

2.1 Customer Access Configuration 

This configuration is as shown in figure 1 of 3GPP TS 04.02 [3]. The present document specifically refers to the Mobile 
Terminations (MTs) which support terminals of the type TEl and TE2 with asynchronous capabilities. The TAF is 
functionally a part of an MTl, MT2 or MTO with an integral asynchronous data capability. 

2.2 Terminal Adaptation Function (TAF) 

The TAF provides facilities to allow manual or automatic call control functions associated with circuit switched 
services. The following functions are also included: 

Conversion of electrical, mechanical, functional and procedural characteristics of the ITU-T V series and ISDN 
type interfaces to those required by the PLMN. 

- Bit rate adaptation of the ITU-T V series data signalling rates and the ISDN 64 kbit/s to that provided in the 
PLMN. 

The mapping functions necessary to convert automatic calling and/or automatic answering procedures of the 
ITU-T recommendation V.250 [22] and parameters for asynchronous operation. 
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The mapping functions necessary to convert S interface signalling to the PLMN Dm channel signalling. 

Flow control (in some cases resulting in non-transparency of data as described in 4.3). 

Layer 2 Relaying (see annex A). 

In-call modification function. 

Synchronization procedure, which means the task of synchronizing the entry to and the exit from the data 
transfer phase between two user terminals. This is described in 3GPP TS 27.001 [10]. 

Filtering of channel control information as described in 3GPP TS 27.001 [10]. 

Terminal compatibility checking. 

Splitting and combining of the data flow in case of multiple substream data configurations. 

3 Terminal Adaptation Functions for transparent 

services 

3GPP TS 03.10 [2] defines connection types for the support of transparent services in GSM whilst 3GPP TR 23.910 [7] 
defines connection types for transparent services in UMTS. 



3.1 Rate Adaptation in GSIVI 



3GPP TS 04.21 [4] describes the rate adaptation scheme to be utilized over the Base Station (BS) to Mobile Station 
(MS) link. 3GPP TS 03.10 [2] refers to the rate adaptation elements to be provided in the MS. 

3.1 .1 Rate Adaptation - R interface 

This is provided as indicated in 3GPP TS 04.21 [4]. 

3.1 .2 Rate Adaptation - S Interface (ITU-T 1.420 [14]) 

VOID 

3.2 Interchange Circuit Signalling Mapping - ITU-T V-series 
interface 

The interchange circuit signalling at the interface between the TE2 and the MT shall conform to ITU-T 
Recommendation V.24 [19]. The signals required at this interface are shown in table 3. 

The mapping of these signals to the pins of a 25 pin D-type connector is given in ISO 2110 [31]. The mapping for a 
commonly used 9 pin connector is given in annex B. 

3.2.1 Mapping of V.24 [1 9] circuits to status bits 

Status bits SA, SB and X are used to convey channel control information associated with the data bits in the data 
transfer state. Table 1 shows the mapping scheme between the ITU-T V.24 [19] circuit numbers and the status bits for 
the transparent mode. It also shows how the unused status bits should be handled. It is derived from the general 
mapping scheme described in annex C. A binary corresponds to the ON condition, a binary 1 to the OFF condition. 

The transport of these status bits by the various channel codings is described in subsequent sections. 
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Table 1 : Mapping scheme at the MT for the transparent mode 



Signal at TE2/MT Interface or 
condition within the MT 


Mapping 
direction: MT to IWF 


Mapping 
direction: IWF to MT 


CT105 


not mapped (note 1) 




CT106 




from status bit X (note 7) 


CT107 




not mapped (note 5) 


CT 108/2 


not mapped (note 6) 




CT109 




from status bit SB (note 7) 


CT133 


not mapped (note 2) 




always ON 


to status bit SA (note 3) 




always ON 


to status bit SB (note 1 ) 




always ON 


to status bit X (note 4) 




ignored by MT 




from status bit SA (note 3) 


NOTE 1 : The SB bit towards the IWF, according to the General Mapping (annex C), could be 
used to carry CT 105. However, CT 105 should always be ON in the data transfer 
state since only duplex operation is supported. Also, many DTEs use the connector 
pin assigned to CT 1 05 for CT 1 33. No interchange circuit shall be mapped to the SB 
bit, which shall always be set to ON in the data transfer state. 

NOTE 2: CT 1 33 is not mapped since there is no flow control in transparent mode. 

NOTE 3: The SA bits in both directions are available only with certain channel codings. 
Therefore, for maximum compatibility, they should not be mapped. 

NOTE 4: The X bit towards the IWF is not mapped and shall always be set to ON in the data 
transfer state since there is no flow control in transparent mode. 

NOTE 5: CT 1 07 is controlled by the channel synchronisation process (07.01 ). 

NOTE 6: CT 1 08/2 may be used in the call setup and answering processes. 

NOTE 7: The status bits are filtered before being mapped to the ITU-T V.24 [19] circuits (3GPP 
TS 27.001 [10]). 



3.2.2 Single slot configurations (TCH/F9.6 or TCH/F4.8) 

3GPP TS 04.21 [4] refers to the frame structure and identifies the use of the status bits for the carriage of signalling 
information in transparent mode. The S bits are put into two groups. SA is carried by bits SI, S3, S6, S8 and SB by bits 
S4, S9 in the ITU-T Recommendation V. 1 10 [27] 80-bit intermediate rate frame. 

3.2.3 Multislot configurations (TCH/F9.6 or TCH/F4.8) 

In transparent multislot configurations, status bits SI, S3 and the X-bit between the D12 and D13 - in the ITU-T 
Recommendation V.l 10 [27] 80-bit intermediate rate frame - are used for transferring substream numbering 
information. The S4-bit is used for frame synchronization between the parallel substreams (reference 3GPP TS 04.21 
[4]). The remaining S bits are put into two groups. SA is carried by bits S6, S8 and SB by bit S9. The remaining X bits 
can be used as described in subclause 3.2.1. 

3.2.4 Channel codings TCH/F1 4.4, TCH/F28.8 

For information on the mapping of the interchange circuit signalling bits in the 14,5 kbit/s multiframe structure, refer to 
3GPP TS 04.21 [4]. There is no SA bit in this channel coding. Only the SB and X bits are carried. 

3.3 Interface Signal Levels - R interface 

The signal levels at the interface between the TE2 and the MT shall conform to ITU-T V.28 [23], or to IrDA IrPHY 
physical signalling standard specification [30], or to PCMCIA 2.1 [29], or to PC-Card 3.0 [29] electrical specification or 
to later revisions. 

3.4 Call Establishment and Clearing Signalling IVIapping 
3.4.1 V-series interface Autocalling/answering 

These procedures are provided according to ITU-T Recommendation V.250 [22] and 3GPP TS 27.007 [11]. 
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For autocalling, during the call establishment phase, i.e. after signalling, calling tone according to ITU-T 
Recommendation V.25 [20] shall be generated in the IWF (3GPP TS 29.007 [13]). 

During the call establishment phase: 

the states of the ITU-T Recommendation V.24 [19] interchange circuits shall be according to 3GPP 
TS 27.001 [10]; 

the data and status bits from the IWF shall not be mapped; 

- the data and status bits towards the IWF shall be according to 3GPP TS 27.001 [10]. 

3.4.2 S Interface (1.420) Signalling Mapping 

Void. 

3.4.3 Call Establishment Manual Operation - Utilizing the Unrestricted 
Digital Capability 

In this case the user shall not hear network supervisory tones or answer tone. The data transfer phase shall be entered 
automatically. 

3.4.4 V-series interface Call Clearing 

This procedure is provided according to ITU-T Recommendation V.250 [22] and 3GPP TS 27.007 [11]. 

During the call clearing phase: 

the states of the ITU-T Recommendation V.24 [19] interchange circuits shall be according to ITU-T 
Recommendation V.24 [19]; 

the data and status bits from the IWF shall not be mapped or used by the MT in any way; 

the data and status bits towards the IWF have no significance and may be set to 1 and OFF respectively. 

4 Terminal Adaptation Functions for non-transparent 

services 

3GPP TS 03.10 [2] defines connection types for the support of non-transparent services in GSM whilst 3GPP TR 
23.910 [7] defines connection types for non-transparent services in UMTS. 

4.1 Data Structure 

4.1 .1 Data Structure on S Interface 

Void. 

4.1 .2 Data Structure on R Interface 

The protocol models for this are described in 3GPP TS 03.10 [2]. The data consists of 7 or 8 bit characters with 
additional start and stop elements. The 7 bit data can additionally have an associated parity bit, 8 bit data cannot have an 
additional parity bit. 

The interchange circuit signalling at the interface between the TE2 and the MT shall conform to ITU-T 
Recommendation V.24 [19]. The signals required at this interface are shown in table 3. 
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The interface shall provide inband (XON/XOFF) and out of band (CT106) flow control. The use of CT133 for out of 
band flow control shall be implemented according to ITU-T Recommendation V.42 [25]. 

4.1 .3 Data Structure Provided by the L2R Function to \he RLP Function 

See annex A. 



4.2 Signalling Mapping 

4.2.1 Interchange Circuit Signalling Mapping - ITU-T V-series interface 

Status bits SA, SB and X are used to convey channel control information associated with the data bits in the data 
transfer state. Table 2 shows the mapping scheme between the ITU-T Recommendation V.24 [19] circuit numbers and 
the status bits for the non-transparent mode. It also shows how the unused status bits should be handled. It is derived 
from the general mapping scheme described in annex C. A binary corresponds to the ON condition, a binary 1 to the 
OFF condition. 

The transport of the status bits by the L2RCOP is described in annex A. 

Table 2: Mapping scheme at the MT for the non-transparent mode 



Signal at TE2/IVIT interface or 
condition within the lUIT 


■mapping 
direction: MT to IWF 


Mapping 
direction: IWF to MT 


CT105 


not mapped (note 1) 




CT106(note4) 




from status bit X (note 7) 


CT107 




not mapped (note 5) 


CT 108/2 


not mapped (note 6) 




CT109 




from status bit SB 


CT 133 (note 8) 


to status bit X (notes 3,8) 




always ON 


to status bit SA (note 2) 




always ON 


to status bit SB (note 1) 




ignored by MT 




from status bit SA (note 2) 


NOTE 1 : The SB bit towards the IWF, according to the General Mapping (annex C), could be 
used to carry CT 105. However, CT 105 should always be ON in the data transfer 
state since only duplex operation is supported. Also, many DTEs use the connector 
pin assigned to CT 1 05 for CT 1 33. No interchange circuit shall be mapped to the SB 
bit which shall always be set to ON in the data transfer state. 

NOTE 2: The SA bits (both directions) are not mapped since CTs 1 07 and 1 08/2 are handled 
locally (notes 5 and 6). 

NOTE 3: The condition of status bit X towards the IWF may also be affected by the state of the 
receive buffer in the MT. 

NOTE 4: The state of CT 1 06 (or other local flow control mechanism) may also be affected by 
the state of the transmit buffer in the MT and the state of the RLP (RR/RNR). 

NOTE 5: CT 1 07 is controlled by the channel synchronisation process (3GPP TS 27.001 [10]). 

NOTE 6: CT 1 08/2 may be used in the call setup and answering processes. 

NOTE 7: For inband local flow control, changes in the condition of the status bit X from the IWF 
also result in the sending of XON or XOFF to the DTE. 

NOTE 8: For inband local flow control, CT 1 33 is not mapped and the status bit X towards the 
IWF is controlled by the reception of XON and XOFF characters from the DTE. 



4.2.2 Call Establishment and Clearing Signalling Mapping 

This is identical to the transparent case with the exception of the transparent/non-transparent element, see clause 5. 

In addition, the L2R/RLP shall give an explicit indication when the link into the connected network is established. If the 
link fails, an explicit "link lost" indication shall be given. 
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4.3 Flow Control 

The passage of flow control information between L2Rs is described in annex A. subclauses 4.3.1, 4.3.2 and 4.3.3 
describe the operation of the flow control mechanisms. These mechanisms apply for all the non-transparent services 
covered by the present document, with the exception of Character Orientated Protocol with No Flow Control which is 
treated in subclause 4.3.4. 

4.3.1 Conditions Requiring Flow Control towards the Network 

The L2R function shall send immediately a "flow control active" indication in the following circumstances: 

(i) If the receive buffer from the radio side reaches a preset threshold (BACKPRESSURE). 

(ii) If local flow control is initiated by the TE2 (see 4.3.3 a) or c)). On receipt of this flow control indication 
transmission of data from the receive buffer towards the TE2 is halted. 

On removal of the buffer congestion or local flow control the L2R shall send a "flow control inactive" indication. 

In addition, for the local flow control condition, transmission of data from the receive buffers shall be restarted. 

4.3.2 Conditions Requiring Flow Control towards TE2 

The L2R functions shall immediately activate local flow control (see 4.3.3 b) or d)) under the following circumstances: 

(i) The transmit buffer reaches a pre-set threshold (BACKPRESSURE). 

(ii) The L2R receives a "flow control active" indication. 
On removal of buffer congestion or receipt of L2R/RLP "flow control inactive" the local flow control shall be removed. 

4.3.3 Local Flow Control 

Two methods of local flow control are allowed: 
Outband: 

a) From TE2: CT133 shall be turned OFF to indicate flow control active, and ON to indicate flow control inactive. 

b) From TAF: CT106 shall be turned OFF to indicate flow control active, and ON to indicate flow control inactive. 
Inband: 

c) From TE2: XOFF (DC3) is sent to indicate flow control active. XON (DCl) is sent to indicate flow control 
inactive. The XON/XOFF characters received from the TE2 are extracted by the L2R from the data stream and 
are not sent across the radio interface. Where XON/XOFF is utilized then the TAF shall generate flow control 
active/inactive immediately, i.e. the XON/XOFF characters do not enter the transmit buffer. 

d) From TAF: As from TE2. 

If the outband method is used, the L2R shall pass the DC1/DC3 characters as data, i.e. no flow control indications shall 
be generated on receipt of DC1/DC3. 

4.3.4 Character Orientated Protocol with No Flow Control 

If the users layer 2 indicates Character Orientated Protocol with no flow control then no flow control is used, i.e. the 
X-bit is not set to OFF and DC1/DC3 characters are passed through as data. 
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4.4 Buffers 

4.4.1 TX Buffers 

Data received on CT103 from the TE2 shall be buffered such that if the MT is unable to transfer the data over the radio 
path then data is not lost. 

The buffer shall be capable of holding the data. Its size is up to the implementers. 

When the buffer is half full, TE2 shall be flow controlled as per 4.3.2, unless Character Orientated Protocol with No 
Flow Control is being used (see 4.3.4). 

4.4.2 RX Buffers 

Data for transfer to the TE2 on CT104 shall be buffered such that if the TE2 is unable to accept data then data 
transferred from the MT is not lost. 

The buffer size should be up to the implementers. 

When the buffer becomes half full, the L2R shall send a "flow control active" indication, unless Character Orientated 
Protocol with No Flow Control is being used. 

4.5 Bit Transparency 

Void. 

4.6 Transportation of "BREAK" condition 

The "BREAK" condition must be recognized by the L2R function and passed immediately to the IWF. The L2R shall 
generate a "BREAK" condition to the TE2 on receipt of a "BREAK" indication from the IWF. 

Annex A describes how the L2R shall transport the "BREAK" indication. 



4.7 Data Compression 



L2R optionally includes a data compression function according to ITU-T V.42bis [26] that spans from the MS to the 
IWF in the MSC. The error correction function is provided by RLP instead of ITU-T Recommendation V.42 [25]. RLP 
XID is used to negotiate compression parameters. L2R includes the ITU-T V.42bis [26] control function especially for 
reinitializing in case of break recognition or RLP reset and error indication by the data compression function 
respectively. 
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Table 3: Minimum set of Interchange Circuits 



Circuit 
Number 


Circuit 
Name 


Ground 


Data 


Control 1 


To 


From 


To 


From 








TE2 


TE2 


TE2 


TE2 


CT102 


Common 
return 


X 










CT103 


Trans- 
mitted 
data 






X 






CT104 


Received 
data 
return 




X 








CT105 


Request 
to send 
(note 2) 










X 


CT106 


Ready 

for 
sending 








X 




CT107 


Data set 
ready 








X 




CT108/2 


Data 

terminal 

ready 










X 


CT109 


Data 

channel 

received 

line 

signal 

detector 








X 




CT125 


Calling 
indicator 
(note 1 ) 








X 




CT133 


Ready for 

Receiving 

(note 2) 










X 



NOTE 1: CT125 is used with the automatic answering function of the TAP. 

NOTE 2: CT105 and CT133 are assigned to the same connector pin on both the standard 25 pin connector 

(ISO 21 10) and the commonly used 9 pin connector (annex B). When this pin is used for CT133 then on 
the DCE (MX) side of the interface CT 105 is treated as being always in the ON condition. Similarly, 
when this pin is being used for CT105 then on the DCE (MT) side of the interface CT 133 is treated as 
being always in the ON condition. As circuit 133 is used only in duplex operation and circuit 105 is used 
only in half duplex operation (which is not supported by GSM or UMTS) there should be no conflict. 



5 Terminal interfacing to 3GPP TS 24.008 [8] IVIapping 

Only those elements/messages that are of particular relevance are considered. 

Interface procedures not directly mappable to 3GPP TS 24.008 [8] are not considered. Mobile management procedures 
of 3GPP TS 24.008 [8] are not considered appUcable. 

Mapping of other call establishment or clearing messages to the S interface e.g. "Call proceeding" etc. has not been 
included. It is assumed these can be mapped directly and as such are of no relevance to the manual interfaces. 
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For the Alternate speech/group 3 facsimile service the TAF shall be able to generate a "Modify" message according to 
the defined procedure in 3GPP TS 24.008 [8]. 



5.1 Mobile Originated Calls 

Call establishment is initiated by the keypad or DTE action: 
a) Setup 



Element 


Derived from 


MMI 


Called 
Address 


Keypad 


Called 
Sub Address 


Keypad 


HLC 


Derived from internal 
settings or MMI infer- mation. 


LLC 


Same as HLC 


BC 


Same as HLC 3GPP TS 27.001 [10] 




gives 
allowed values 



b) Release Complete 



Element 


Derived from 


MMI 


Cause 


Display 
(optional) 



5.2 IVIobile Terminated Calls 

Call establishment is initiated by receipt of Setup at the MS: 
a) Setup 



Element 


Mapped on to 


MMI 


Called 
Address 

Called Sub 
Address 

HLC 
LLC 
BC 


Display 
(optional) 

Display 
(optional) 

Display 
(optional) 

Display 
(optional) 

Display 
(optional) 



£75/ 



3GPP TS 27.002 version 3.5.0 Release 1999 



17 



ETSI TS 127 002 V3.5.0 (2000-09) 



b) Call Confirm 

Information for the BC element in the call confirm shall be derived from e.g. MMI or by internal settings. 

c) Connect 

Connect is sent in response to connect from MMI. 

5.3 Call Clearing 
5.3.1 Mobile initiated 

Call clearing is initiated by the keypad or DTE action: 
Disconnect 



Element 


Derived from 


MMI 


ITU-T V.250 [22] 


Cause 


Keypad 


See section 3.4.4 



5.3.2 Network initiated 

Call clearing is initiated by receipt of Disconnect at the MS: 
Disconnect 



Element 


Mapped on to 


MMI 


ITU-T V.250 [22] 


Cause 


Display 
(optional) 


Unsolicited result codes 
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Annex A (normative): 
L2R Functionality 

A.1 Introduction 

This annex describes the L2R functionality for non-transparent character oriented protocols. The general aspects of 
L2Rs are described in 3GPP TS 27.001 [10]. Figure 1 shows the 3 sub-functions of a character oriented L2R. 



CORE 



CONTP 



CONTP 
Entity 




L2RC0P 



CONTP Character Oriented Non-Transparent Protocol. 
CORE Character Oriented Relay Entity. 
L2RC0P L2R Character Oriented Protocol. 

Figure 1 

Section 2 describes the L2R Character Oriented Protocol (L2RCOP) and section 3 the use of the L2RCOP. 



A.2 The L2RC0P 



Information is transferred between L2Rs in fixed length n octet Protocol Data Units (PDUs). This corresponds to the 
fixed length of the RLP frame information field. The octets within the L2RCOP-PDU are numbered to n-1; octet is 
transmitted first. The value of n depends on the negotiated RLP version and frame type ( 3GPP TS 24.022[9]). The bits 
within the octets are numbered 1 to 8; bit 1 is transmitted first. 

The RLP version value 2 indicates RLP multi-link operation. The RLP version value or 1 indicates RLP single-link 
operation. 

Each octet contains a status octet, an information octet or fill. 

Octet contains either a status octet or a user information octet. 

Octet shall always contain a status octet in case at least one status octet is transported in the L2RCOP PDU. In 
RLP-versions and 1 a PDU always carries at least one status octet. In RLP version 2 a PDU carries status 
octet(s) only if actual status change(s) has taken place within the period represented by the PDU. Here the L2R 
status flag in the RLP version 2 header is set to 1 when status octet(s) is carried in the PDU. 

Status octets contain 3 status bits and 5 address bits. In cases where two status octets within the PDU are 
separated by more than 23 octets, the first status octet in octet m is followed by a pointer octet in octet m-nl 
forming a two-octet status field. The pointer octet contains one reserved bit and seven address bits indicating the 
number of characters between the status field and the second status octet. 

- The 3 status bits correspond to SA, SB and X in ITU-T Recommendation V.llO [27]. The SA, SB and X bits 
use bit positions 8, 7 and 6 in the status octets. When a status bit changes the current state of all three bits shall 
be transmitted. 

Information octets are character octets or encoded character octets. 



£75/ 



3GPP TS 27.002 version 3.5.0 Release 1 999 19 ETSI TS 1 27 002 V3.5.0 (2000-09) 

Character octets are coded in the following way: 

The first bit of the character received/transmitted corresponds to bit position 1 in the octet and the seventh 
bit corresponds to bit 7. For order of transmission of IA5 characters see ITU-T Recommendation V.4 [15]. 

7 bit characters are padded with a in bit position 8. Received parity (if used) is inserted in bit position 8, if 
parity is not used bit 8 is set to 0. 

Any start/stop bits are removed by the L2R. 

Encoded character octets are provided by the compression function. They are encoded according to ITU-T 
Recommendation V.42bis [26]. 

Information octets are inserted into L2RCOP-PDUs in order of transmission in octets 1 to n-1 for RLP single- 
link operation, in octets 1 to n-1 for RLP multi-link operation with status octet transportation, and in octets to 
n-1 for multi-link operation with no status octet transportation. 

The address field in the status octets indicates the position of next status octet within the L2RCOP-PDU. This 
indicates the number of characters between status octets. Thus if two status octets are inserted into 
L2RCOP-PDU at offsets 1 and m the address value shall be defined by m-1-1. Address bit 2" corresponds to bit 1 
in the status octets. Address bit 2' to bit 2 etc. 

Status octets are inserted in the character stream whenever a status change needs to be transmitted. 

Only address values 1 to n-2 (n-2 < 23) in the address field of status octets are used for addressing purposes. The 
implication of not allowing address value to be used for addressing is that two status octets cannot be sent after 
each other. The remaining codes are used to indicate: 

Last status change, remainder of L2RC0P-PDU empty. Address field value 3 1 . 

Last status change, remainder of L2RCOP-PDU full of characters. Address field value 30. 

Destructive break signal, remainder of L2RCOP-PDU empty. Address field value 29. 

Destructive break acknowledge, remainder of L2RCOP-PDU empty. Address field value 28. 

- L2RCOP-PDU contains at least two status octets which are separated by more than 23 characters; the 
address-field value in the first octet of the two-octet status field is 27 and the address bits in the pointer 
octet of the status field indicate the number of characters between the two-octet status field and the next 
status octet. 

Address field values from n-1 to 26 are reserved. In case of a PDU more than 25 octets in length, address 
field values from 24 to 26 are reserved. 

When it is necessary to insert a status octet into the character stream when no status change has occurred, e.g. to 
indicate that the reminder of a L2RCOP-PDU is empty or to indicate a break signal, the current status shall be 
repeated. 

In case when 64 data octets are carried by a 66-octet PDU, a status octet is carried in octet and another status 
octet within the first 24 data octets. (The first status octet gives the address of the second status octet, which 
carries value 30 in its address field). 

Three examples of an L2RCOP PDU are shown in figure 2. 
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n-1 



8 


7 


6 


5 


4 


3 


2 1 


SA 


SB 


X 











1 1 


1 


1 











1 


1 1 


1 


1 





1 








1 1 


1 


1 








1 


1 


1 


SA 


SB 


X 


1 


1 


1 


1 1 







IA5 "G" (odd parity) 
IA5 "S" (odd parity) 
IA5 "M" (odd parity) 
(last status cliange, rest of PDU empty) 



Figure 2a: Single-link RLP and multi-link RLP with status octet transfer in PDU 



n-1 



8 
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6 


5 


4 


3 


2 1 


1 


1 





1 








1 1 


1 


1 











1 


1 1 


1 


1 





1 








1 1 


1 


1 








1 


1 


1 






1 


1 








1 


1 


1 



IA5 "S" (odd parity) 
IA5 "G" (odd parity) 
IA5 "S" (odd parity) 
IA5 "M" (odd parity) 



IA5 "M" (odd parity) 



Figure 2b: Multi-link RLP L2RC0P PDU with no status octet transfer 
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1 


1 
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SA 


SB 


X 


1 


1 





1 


1 
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1 


1 




SA 


SB 


X 














1 


1 


1 








1 


1 





1 


SA 


SB 


X 


1 


1 


1 


1 







1 


1 








1 


1 


1 


1 



IA5 "IVI" (odd parity) 
IA5 "A" (odd parity) 
IA5 "R" (odd parity) 



IA5 "K" (odd parity) 



IA5 "O" (odd parity) 



Figure 2c: A 66-octet RLP L2RC0P PDU with status octets separated by more than 23 octets 
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A.3 Use of the L2RC0P 

The CORE relays status changes, break conditions and characters in both directions between the CONTP entity and the 
L2RC0P entity. 

The L2RCOP entity performs the following functions. 

A.3.1 Radio Link Connection Control 

Given appropriate indications from the signalling mechanisms the L2RCOP entity uses the services of the radio link to 
establish and release the connection to its peer L2RC0P entity in the IWF. 

A.3.2 Data Transfer 

The L2RCOP entity shall assemble and disassemble L2RCOP-PDUs. Data characters are assembled into 
L2RCOP-PDUS until either: 

- the PDU is full; 

the Radio Link service can accept another Radio Link service Data Unit. 

L2RC0P-PDUs are transferred to the peer L2RCOP entity using the data transfer services of the radio link. 

A.3.3 Status Transfer 

The L2RC0P entity transfers interface status information between L2Rs using bits SA, SB and X in the status octets in 
L2RC0P-PDUS. Status changes are inserted in the L2RC0P-PDU in the position corresponding to the position in the 
character stream that the interface status change occurred. When the RLP is established or reset a L2RCOP-PDU with 
the current status values shall be sent. 

The general mapping between ITU-T V.24 [19] interface circuit numbers and status bits is described in annex C. A 
binary corresponds to the ON condition, a binary 1 to the OFF condition. The specific mapping at the MT for the 
non-transparent bearer service is given in subclause 4.2.1. The mapping schemes used at the IWF are given in 3GPP 
TS 29.007 [13]. 

A.3.4 Flow Control 

Flow control information is transferred between L2Rs in 2 ways, these are: 
back pressure caused by L2R buffer conditions. 
use of the X-bit in status octets: 

flow control active, X-bit = ONE. 
flow control inactive, X-bit = ZERO. 

A.3. 5 Break 

The transfer of break conditions between L2Rs is via the status octets with appropriate coding of the address field. 
Where the "Break Signal" is generated it shall conform to the definition shown in ITU-T Recommendation X.28 [28]. 

A.3. 5.1 Normal Realization 

The L2RCOP-PDU contains the mandatory status octet coded as the Destructive Break. 

Upon the receipt of the "Break Signal", the L2R shall destroy any existing data in front of the Break Signal in the same 
direction, and all the buffered data in the other direction. The L2R shall then pass the Break Signal immediately on. 
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The termination of a break condition is indicated by sending an L2RCOP-PDU containing characters. 

A.3.5.2 Realization in case of Data Compression is used 

If the data compression function is used L2RCOP has to ensure the synchronization of the encoder and decoder 
according to ITU-T Recommendation V.42bis [26]. 

Upon receipt of a L2RC0P-PDU containing a status octet that signals a Destructive Break L2R destroys all data in the 
TX and RX buffer and re-initializes the compression function. Then L2R shall transmit an L2RC0P-PDU that contains 
the mandatory status octet coded as the Destructive Break Acknowledge. After that L2R shall restart the data transfer. 

Upon an receipt of the "Break Signal" by the CONTP, the L2R destroys any existing data in the TX and RX buffer and 
shall then pass the Break Signal immediately by using L2RCOP-PDU containing a status octet coded as the Destructive 
Break. L2R shall wait for a L2RCOP-PDU containing a mandatory status octet coded as Destructive Break 
Acknowledge. Following data received by the CONTP shall be stored in the TX buffer. Data received in 
L2RCOP-PDUs shall be discarded. After reception of the L2RCOP-PDU containing a mandatory status octet coded as 
Destructive Break Acknowledge L2R shall re-initialize the data compression function and restart the data transfer. 
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Annex B (informative): 

Use of a 9 pin connector as an l\/IT2 type interface 

For asynchronous data communications many of the physical pins on a standard 25 pin D-type connector 

(ISO 21 10 [31]) are not used. As a result many communication devices have only a 9 pin connector to allow them to be 

made smaller. This interface is a MT2 type providing the correct ITU-T Recommendation V.24 [19] signals are 

supported. 

Table Bl gives the pin assignments for a 9 pin connector. Two variants are permitted: 

1. Outband flow control 

When outband (CT 133) flow control is required, pin number 7 carries CT 133 (Ready for Receiving). In this case 
CT 105 is not mapped to any physical pin. On the MT2 side of the interface, CT 105 is treated as being always in the 
ON condition. 

2. No outband flow control 

When no outband (CT 133) flow control is required, pin number 7 may carry CT 105 (Request to Send). In this case 
CT 133 is not mapped to any physical pin. On the MT2 side of the interface, CT 133 is treated as being always in the 
ON condition. 

Table Bl : Interchange circuit mappings 



ITU-T V.24 [19] Circuit 
Number 


Circuit Name 


Pin Number 


CT102 


Common ground 


5 


CT103 


TxD 


3 


CT104 


RxD 


2 


CT105 


RTS 


7 (note) 


CT106 


RFS (CIS) 


8 


CT107 


DSR 


6 


CT 1 08/2 


DTR 


4 


CT109 


DCD 


1 


CT125 


CI 


9 


CT133 


RFR 


7 (note) 


NOTE: Only one of these mappings may exist at any one time. 
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Annex C (informative): 

General mapping of ITU-T V.24 [19] circuits to channel 

status bits 

In the data transfer state, status bits SA, SB and X can be used to convey channel control information associated with 
the data bits. Table CI shows the general mapping scheme between the ITU-T V.24 [19] circuit numbers and the status 
bits. A binary corresponds to the ON condition, a binary 1 to the OFF condition. The specific mappings for the 
various PLMN bearer types are given elsewhere in the present document. 

Table CI : General mapping scheme at the MT 



Signal at TE2/IVIT 
interface 


Status bit 
direction: IMT to IWF 


Status bit 
direction: IWF to IVIT 


CT105(note3) 


SB 




CT106(note1) 




X 


CT107 




SA 


CT 1 08/2 


SA 




CT109 




SB 


CT133(note3) 


X (note 2) 




NOTE 1 : The condition of CT 1 06 may also be affected by tlie state of 
any transmit buffer in the IVIT. 

NOTE 2: The condition of Status bit X towards the IWF may also be 
affected by the state of any receive buffer in the MT. 

NOTE 3: CT1 05 and CT1 33 are assigned to the same connector pin on 
both the standard 25 pin connector (ISO 2110) and the 
commonly used 9 pin connector (annex B). When this pin is 
used for CT133 then on the IVIT side of the interface CT 105 is 
treated as being always in the ON condition. SB towards the 
IWF shall therefore also always be ON. 
Similarly, when this pin is being used for CT1 05 then on the 
MT side of the interface CT 133 is treated as being always in 
the ON condition. X towards the IWF shall therefore also 
always be ON. 

As circuit 133 is used only in duplex operation and circuit 105 
is used only in half duplex operation (which is not supported by 
GSM or UMTS) there should be no conflict. 
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Annex D (informative): 
Change history 
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